目次 カーネルパニックとは？ Mac OS X の Darwin カーネルにおける PowerPC の例外処理の基本 パニックはどのように表示されるのか パニック表示の読み方 クラッシュ原因の特定 要約 参考文献 ダウンロード

Mac OS X でカーネルがクラッシュすると、システムによりパニックメッセージが表示されます。この時点で、システムを再起動する必要があります。しかし、再起動ボタンを押す前にクラッシュの原因を突き止めるにはどうしたらよいでしょうか？ このテクニカルノートでは、カーネルパニックについて説明します。具体的には、カーネルパニックとは何であるかを説明し、パニックの原因となるコードのデバッグ方法を紹介します。 Mac OS X の基盤は、Darwin として広く知られるコアオペレーティングシステムです。Darwin カーネルは、PowerPC と Intel x86 の両方のアーキテクチャで動作しますが、このテクニカルノートでは、PowerPC での例外処理に限定して説明します。 このテクニカルノートには、Darwin リポジトリから入手可能なソースファイルのリンクを掲載してあります。これらのファイルにアクセスするには、ユーザ名とパスワードが必要です。ユーザ名とパスワードは、Apple Public Source License に同意することにより入手できます。 [2002 年 11 月 11 日]

カーネルパニックとは？

UNIX では、パニックはカーネル¹ によって検出される回復不可能なシステムエラーであり、ユーザ空間のコードによって検出される同様のエラーとは異なります。カーネルコードは、「sys/systm.h」ヘッダファイルにある panic 関数を呼び出すことによって、このような状態を示すことができます。しかし大部分のパニックは、無効なメモリアドレスの参照のように、カーネルコード中の未処理のプロセッサ例外の結果として発生します。これらは、通常、パニックに至るまでのコールチェーンのどこかにバグがあることを示しています。

先頭に戻る

Mac OS X の Darwin カーネルにおける PowerPC の例外処理の基本

例外とは、プロセッサが遭遇し、特別な処理を必要とする状態のことです。PowerPC マイクロプロセッサファミリは、スーパーバイザ状態に切り替え、特定のレジスタにプロセッサの状態を保存し、例外ハンドラルーチンへジャンプすることにより、例外を処理します。主要な例外（データメモリアクセス、アラインメントなど）には、PowerPC アーキテクチャで定義される絶対アドレスに、それぞれ固有の例外ベクタがあります。

最も一般的な例外は以下の通りです。

• DSI（データ記憶域の割り込み、またはデータメモリアクセス）例外。これは、NULL ポインタのデレファレンスなど、無効なメモリアドレスにあるデータをアクセスしようとしたことが原因で発生します。
• ISI（命令記憶域の割り込み）例外。これは、0 のアドレス位置への分岐など、無効なメモリアドレスで命令を実行しようとしたことが原因で発生します。
• 無効な命令例外。これは、無効な opcode で命令を実行しようとしたことが原因で発生します。

PowerPC の例外処理の詳細は、『PowerPC Microprocessor Family: The Programming Environments』（以下、『TPE』）の第 6 章（Chapter 6）に記載されています。

例外処理に関わるいくつかのプロセッサレジスタは、処理されない例外が原因でパニックが発生すると画面に表示されます。このようなレジスタは、以下のようなものです。

DSISR

ダイレクトストアエラー例外、すなわち、integer double-word のロードまたはストア命令のオペランドがワードにアラインされないといった、DSI およびアラインメント例外の原因を示します。

データアクセスレジスタ (DAR)

DSI 例外またはアラインメント例外の原因となる、メモリ要素の実効アドレスを格納します。

マシン状態レジスタ (MSR)

プロセッサの状態を定義します。設定値には、割り込み許可、権限レベル、マシンチェック許可、アドレス変換ビットがあります。

マシンステータスの保存/リストアレジスタ 0 (SRR0)

例外処理の後、命令処理の再開位置を計算するために使用するアドレスを格納します。例外によっては、これは、例外を発生させた命令、またはプログラムフロー中の次の実効アドレスになります。このレジスタは、パニック表示において PC（プログラムカウンタ）として表示されます。

マシンステータスの保存/リストアレジスタ 1 (SRR1)

例外に固有の情報と、例外発生時に MSR から選択されたビットを格納します。このレジスタは、パニック表示において MSR として表示されます。

リンクレジスタ (LR)

直前のサブルーチンコール（bl: 分岐後リンク）命令に続く命令のアドレスを格納します。

汎用レジスタ 1 (GPR1)

パラメタとその他の一時的なデータ項目を格納するスタックポインタとして使用されます。このレジスタは、パニック表示において R1 として表示されます。

PowerPC レジスタの設定の詳細については、『TPE』の第 2 章（Chapter 2）に記載されています。

PowerPC 例外を処理する場合、Darwin カーネルは下記の実行フローに従います。

最後の関数 (unresolved_kernel_trap) は、パニック情報が表示される場所です。

先頭に戻る

パニックはどのように表示されるのか

リスト 1 に、Mac OS X 10.2.1 システムの典型的なパニック表示を示します。参照しやすくするため、行番号を追加してあります。

 リスト 1. パニックダンプの例

1 Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0xdeadbeef PC=0x0e692550
2 Latest crash info for cpu 0:
3    Exception state (sv=0x0EB5DA00)
4       PC=0x0E692550; MSR=0x00009030; DAR=0xDEADBEEF; DSISR=0x42000000; LR=0x0E692530;
R1=0x081DBC20; XCP=0x0000000C (0x300 - Data access)
5       Backtrace:
6          0x0E6924A8 0x00213A88 0x00213884 0x002141D4 0x00214830
0x00204CB0 0x00204C74
7       Kernel loadable modules in backtrace (with dependencies):
8          com.apple.dts.driver.PanicDriver(1.0)@0xe691000
9             dependency: com.apple.iokit.IOUSBFamily(1.9.2)@0xed9c000
10 Proceeding back via exception chain:
11    Exception state (sv=0x0EB5DA00)
12       previously dumped as "Latest" state. skipping...
13    Exception state (sv=0x0EB64A00)
14       PC=0x00000000; MSR=0x0000D030; DAR=0x00000000;
DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)
15
16 Kernel version:
17 Darwin Kernel Version 6.1:
18 Fri Sep  6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj‾2/RELEASE_PPC
19
20
21 Memory access exception (1,0,0)
22 ethernet MAC address: 00:0a:11:22:33:44
23 ip address: 169.254.180.203
24
25 Waiting for remote debugger connection.

    

Mac OS X 10.2 からは、パニックは、図 1 に示すように、複数の言語による警告として表示されます。システムを再起動したあと、「panic.log」というファイルが「/Library/Logs」に生成されます。このファイルには、画面上のパニックダンプと同じデータが格納されています。

図 1. Mac OS X 10.2 のパニック警告

boot-args の debug パラメタを通じてリモートデバッグが有効になっている場合は、パニック警告またはテキストによるパニックダンプのどちらかが表示されると、システムはリモート GDB デッバッガセッションからの接続待ち状態になります。リモート（2 台のマシン）デバッグの詳細については、Hello Debugger チュートリアルを参照してください。

リモートデバッグに影響を及ぼすフラグの一覧は、『Inside Mac OS X: Kernel Programming』の Table 19-1 に示されています。

先頭に戻る

パニック表示の読み方

ここでは、パニック表示の各行について、その行を表示させているカーネル ソースファイルと関数の名前を示し、その次に各行の意味を説明します。

行 1 xnu/osfmk/ppc/trap.c: unresolved_kernel_trap

Unresolved kernel trap: パニックの原因を説明している文章。これは panic 関数に渡されるパラメタです。

(cpu 0): 例外が発生した CPU の番号。マルチプロセッサシステムではこの情報が役立ちます。マルチプロセッサシステムでは、ほかのプロセッサが稼動し続けていても、1 つのプロセッサでパニックが発生する可能性があります。

0x300 - Data access: トラップ名。これは、例外を説明しています。トラップ名は、「xnu/osfmk/ppc/trap.c」ファイルの trap_type 配列にあります。ハードウェア例外コードの trapno（「xnu/osfmk/ppc/exception.h」ヘッダファイルで定義されています） は、例外ハンドラ xnu/osfmk/ppc/lowmem_vectors.s: L_handlerXXXX（XXXX は PowerPC の例外ベクタ）によって初期設定されます。trap_type 配列へのインデックスは、T_VECTOR_SIZE で trapno を割ることによって計算されます。T_VECTOR_SIZE は、やはり「xnu/osfmk/ppc/exception.h」ヘッダで、4（関数ポインタのサイズ）になるように定義されています。

先頭の 0x300 は PowerPC の例外ベクタです。この値を使って、『TPE』の第 6 章（Chapter 6）の特定の例外についての詳細を調べることができます。

DAR: データアクセスレジスタの内容
PC: SRR0 レジスタの内容

DAR と PC の解釈は、各例外の定義によって変わります。

リスト 1 に戻る

行 2 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 3 xnu/osfmk/ppc/model_dep.c: print_backtrace

例外の状態は、型が savearea のデータ構造体に格納されます（「xnu/osfmk/ppc/exception.h」を参照）。sv は、一番新しい例外を表す savearea のアドレスです。

リスト 1 に戻る

行 4 xnu/osfmk/ppc/model_dep.c: dump_savearea

PC: SRR0 の内容
MSR: SRR1 の内容
DAR: データアクセスレジスタの内容
DSISR: DSISR の内容
LR: リンクレジスタの内容
R1: GPR1 の内容
XCP: これはレジスタではなく、現在の例外の savearea に格納されている例外コードです。この次にトラップ名（行 1 参照）が続きます。

リスト 1 に戻る

行 5 xnu/osfmk/ppc/model_dep.c: dump_backtrace

リスト 1 に戻る

行 6 xnu/osfmk/ppc/model_dep.c: dump_backtrace

これは、実際のスタックバックトレースです。最初のスタックポインタは、savearea の GPR1 の値です。スタックフレームのリンケージエリアにある LR 値が出力され、次に、スタックフレームに保存されている GPR1 値を使用して、次のスタックフレームが指定されます。最大 32 までのスタックフレームが出力されますが、ゼロの GPR1 に遭遇した場合や、以前の例外を表す savearea が存在する場合は、スタックフレームの数はもっと少なくなります。

Mac OS X で使用されている PowerPC スタックの詳細は、『Inside Mac OS X: Mach-O Runtime Architecture』の「Power PC Stack Structure」のセクションに記載されています。

バックトレースは、例外を引き起こしたコールチェーンを再現するのに使用できるため、一般にパニックダンプの中で最も役立つ情報です。これについては、後述の「クラッシュの原因の特定」のセクションで詳しく説明します。

リスト 1 に戻る

行 7 xnu/osfmk/kern/kmod.c: kmod_dump

この行は、バックトレースのアドレスを見て、バックトレースにある各カーネルローダブルモジュールのモジュール名、バージョン、開始アドレスを出力します（カーネルローダブルモジュールは、カーネル拡張、すなわち kext の実行可能部分にすぎません）。また、同じ情報が、各カーネル機能拡張 (kext) の依存関係のために出力されます。モジュール名とバージョンは、kextstat コマンド（Mac OS X v10.2 以前では、kmodstat）によって表示されるものと同じであり、Project Builder のビルド設定の MODULE_NAME と MODULE_VERSION の値でもあります。依存関係は、Project Builder のバンドル設定の OSBundleLibraries プロパティで指定されています。

リスト 1 に戻る

行 8 xnu/osfmk/kern/kmod.c: kmod_dump

リスト 1 に戻る

行 9 xnu/osfmk/kern/kmod.c: kmod_dump

リスト 1 に戻る

行 10 xnu/osfmk/ppc/model_dep.c: print_backtrace

各例外の状態がダンプされています。最初の 1 つは、すでに行 3 から行 6 までに示されているため（どちらの場所も sv の値が同じです）、省略します。

リスト 1 に戻る

行 11 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 12 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 13 xnu/osfmk/ppc/model_dep.c: dump_savearea

行 3 と同じです。

リスト 1 に戻る

行 14 xnu/osfmk/ppc/model_dep.c: dump_savearea

行 4 と同じです。

リスト 1 に戻る

行 15 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 16 xnu/osfmk/ppc/model_dep.c: print_backtrace

この行は、ビルド時に設定されたカーネルのグローバル変数 version の値を出力しています。この値には、改行文字が埋め込まれているため、行 17 から行 19 まで折り返されて表示されています。

文字列“Fri Sep 6 23:24:34 PDT 2002”は、カーネルがビルドされた日付と時刻です。文字列“xnu/xnu-344.2.obj‾2/RELEASE_PPC”は、カーネルがビルドされたオブジェクトディレクトリです。“xnu-344.2”の部分は、このカーネルのビルドに使われた Darwin ソースリビジョンの CVS タグと同じバージョン番号が含まれます（この場合は Apple-344-2）。これにより、カーネル自体のソースデバッグが必要な場合に、カスタムカーネルをビルドすることができます。

実行中のカーネルのバージョンを見るには、リスト 2 に示す sysctl コマンドを使用します。

リスト 2. カーネルバージョンの表示 [localhost:‾] me% sysctl kern.version kern.version = Darwin Kernel Version 6.1: Fri Sep 6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj‾2/RELEASE_PPC [localhost:‾] me%

カスタムのカーネルをビルドする手順は、『Inside Mac OS X: Kernel Programming』の「Building and Debugging Kernels」の章に記載されています。

リスト 1 に戻る

行 17 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 18 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 19 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

行 20 xnu/osfmk/ppc/model_dep.c: print_backtrace

リスト 1 に戻る

次の 3 つの呼び出しは、何も出力しません。

xnu/osfmk/ppc/misc_asm.s: Call_Debugger
xnu/osfmk/ppc/model_dep.c: Call_DebuggerC
xnu/osfmk/kdp/ml/ppc/kdp_machdep.c: kdp_trap

リスト 1 に戻る

行 21 xnu/osfmk/kdp/kdp_udp.c: kdp_raise_exception

この行は、例外メッセージと、そのあとに例外番号、コード、サブコードが括弧で囲まれて続きます。

exception:「xnu/osfmk/kdp/ml/ppc/kdp_machdep.c」で定義されている配列 kdp_trap_codes は、PowerPC 固有の例外コードを、KDB（カーネルデバッガ）で使用される一般的な Mach 例外コードに変換するために使われます。Mach コードは、「mach/exception_type.h」で定義されていますが、処理されない PowerPC の例外のほとんどが EXC_BAD_ACCESS (1) にマップされるため、これは通常は役に立ちません。

exception_message: Mach 例外コードは、例外を説明するテキストメッセージを調べるのに使われます。このメッセージテーブル exception_message は、「xnu/osfmk/kdp/kdp_udp.c」に定義されています。

code と subcode は使用されず、常に 0 となります。

リスト 1 に戻る

行 22 xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

この行は、パニックが発生したマシンの組み込みの Ethernet MAC アドレスです。このアドレスと IP アドレス（行 23）を使って、リモートデバッグセッションが確立されます。

リスト 1 に戻る

行 23 xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

この行は、カーネルパニックが発生したマシンの IP アドレスです。このアドレスとイーサネット MAC アドレス（行 22）を使って、リモートデバッグセッションが確立されます。

リスト 1 に戻る

行 24 xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

リスト 1 に戻る

行 25 xnu/osfmk/kdp/kdp_udp.c: kdp_connection_wait

この時点で、システムはリモートデバッガからの接続待ち状態にあります。

リスト 1 に戻る

先頭に戻る

クラッシュの原因の特定

ここでは、皆さんの顧客またはテスト担当者の一人が、皆さんのカーネル拡張 (kext) をインストールしてあり、その環境でカーネルパニックを経験したものと想定します。幸い、その人から先述のパニックダンプが送られてきています。このような場合、どのようにしてクラッシュの原因を特定すればよいのでしょう？

まず、パニックが発生したマシンと同じバージョンの OS を実行します。パニックダンプにあるカーネルと kext のバージョン番号を使って、正しいバージョンを実行していることを確認します。

次に、クラッシュの種類と、どのカーネル拡張でクラッシュが起こったかを確認します。ここでは、0x0E692550 を含んでいる プログラムカウンタによってデータアクセス例外が発生しました。ロードされたカーネル拡張のリストを見ると、最も近いのは、アドレス 0x0E691000 からロードされている com.apple.dts.driver.PanicDriver です。これはデータアクセス例外であるため、DAR には、アクセスできなかったアドレスが格納されています。このケースでは、0xDEADBEEF のメモリにアクセスしようとして例外につながりました。

バックトレースを使って、クラッシュに至った一連の呼び出しを、より正確に理解することができます。バックトレースを解読するには、バックトレースにリストされているカーネルと各カーネル拡張ごとに、再配置されたシンボルファイルを作成する必要があります。kext のロードアドレスは毎回変わる可能性が高いため、kext をロードするたびに、新しいシンボルファイルのセットを生成する必要があります。

Mac OS X v10.2 からは、シンボルファイルの生成は、リスト 3 に示すように、kextload コマンドを通じて行われます。-s で、シンボルファイルが書き込まれるディレクトリを指定します。-n オプションを使うと、kextload は各カーネル拡張とその依存関係のロードアドレスを尋ねてきます。

[localhost:‾] me% sudo kextload -s /tmp -n PanicDriver/build/PanicDriver.kext/
Password:
kextload: notice: extension PanicDriver/build/PanicDriver.kext/ has debug properties set
...some output elided...
enter the hexadecimal load addresses for these modules:
com.apple.iokit.IOUSBFamily: 0xed9c000
com.apple.dts.driver.PanicDriver: 0xe696000

この結果、モジュールごとに 1 つずつ、「<module-name>.sym」という名前のシンボルファイルが生成されます。

v10.2 以前のバージョンの Mac OS X では、リスト 4 に示すように、kmodsyms コマンドを通じてシンボルファイルが生成されます。各カーネル拡張とその依存関係のロードアドレスを指定する必要があります。依存関係が複数ある場合は、別々の -d オプションを使って 1 つずつ入力します。-v オプションを使うと、同じくリスト 4 に示すように詳細な形式で出力されます。

[localhost:‾] me% kmodsyms -v -k /mach_kernel ¥
-d /System/Library/Extensions/IOUSBFamily.kext/Contents/MacOS/IOUSBFamily@0xed9c000 ¥
-o /tmp/com.apple.dts.driver.PanicDriver.sym
PanicDriver/build/PanicDriver.kext/Contents/MacOS/PanicDriver@0xe691000
kmodsyms: Returning fake load address of 0x ed9cb10
kmodsyms: kmod name:com.apple.iokit.IOUSBFamily
kmodsyms: kmod start @ 0xedab39c
kmodsyms: kmod stop  @ 0xedab408
kmodsyms: Returning fake load address of 0x e691b10
kmodsyms: kmod name:com.apple.dts.driver.PanicDriver
kmodsyms: kmod start @ 0xe692574
kmodsyms: kmod stop  @ 0xe6925e0
[localhost:‾] me%

皆さんのカーネル拡張には、それが Project Builder の Development ビルドスタイルを使ってビルドされたものであれば、完全な行番号と関数名の情報が付きます。それ以外のカーネルコードには、リンク先として十分な名前情報しか含まれません。

次に、リスト 5 に示すように、add-symbol-file コマンドを使って、シンボルファイルを GDB にロードします。

[localhost:‾] me% gdb /mach_kernel
GNU gdb 5.1-20020408 (Apple version gdb-228) (Sun Jul 14 10:07:24 GMT 2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-macos10".
(gdb) add-symbol-file /tmp/com.apple.dts.driver.PanicDriver.sym
add symbol table from file "/tmp/com.apple.dts.driver.PanicDriver.sym" at
(y or n) y
Reading symbols from /tmp/com.apple.dts.driver.PanicDriver.sym...done.
(gdb)

Mac OS X v10.2 以降ではよくあることですが、複数のシンボルファイルがある場合は、それぞれについて add-symbol-file コマンドを繰り返します。

I/O Kit の C++ 関数名の場合は、名前をより読みやすくするため、名前を展開すると役立つことがあります。これを行うには、コマンド set print asm-demangle on を使うのが便利です。このコマンドは、ディスアセンブルリストにある C++ と Objective-C の名前の展開を制御します。

「メモリ調査」コマンド x/i <address> を使って、プログラムカウンタ (PC) にある命令を表示します。例外のタイプによって、例外の原因となった命令または、その直後の命令のいずれかが表示されます。リスト 6 に例を示します。

(gdb) set print asm-demangle on
(gdb) x/i 0xe692550
0xe692550 <com_apple_dts_driver_PanicDriver::start(IOService*)+276>:stw     r0,0(r9)
(gdb) 

次に、バックトレースで指定されたアドレスごとに、コマンド x/i <address>-4 を使って、そのアドレスの直前の命令を表示します。これにより、アドレスが位置している関数の名前が分かります。バックトレースからディスアセンブルされた各命令は、分岐命令の形式になっているはずです。その理由を理解するには、関数呼び出しの実行前に保存されたリターンアドレスのリストがバックトレースであることを思い出してください。ディスアセンブルされたものが分岐命令以外の何かを示している場合は、シンボルファイルが正しく生成されていないか、OS のバージョンがパニックを発生したマシンのものと同一でないことを暗示しています。

リスト 7 は、リスト 1 に示したバックトレースの復号結果を示しています。

(gdb) x/i 0x0e6974a8-4
0xe6974a4 <com_apple_dts_driver_PanicDriver::start(IOService*)+104>:bl
0xeb4f5b0 <com_apple_dts_driver_PanicDriver::start(IOService*)+372>

(gdb) x/i 0x0213a88-4
0x213a84 <IOService::startCandidate(IOService*)+116>:bctrl

(gdb) x/i 0x213884-4
0x213880 <IOService::probeCandidates(OSOrderedSet*)+2096>:bctrl

(gdb) x/i 0x2141d4-4
0x2141d0 <IOService::doServiceMatch(unsigned long)+452>:bctrl

(gdb) x/i 0x214830-4
0x21482c <_IOConfigThread::main(_IOConfigThread*)+280>:bctrl

(gdb) x/i 0x204cb0-4
0x204cac <ioThreadStart+56>:bctrl

(gdb) x/i 0x204c74-4
0x204c70 <IOLibInit+184>:blr
(gdb)

先頭に戻る

要約

このテクニカルノートで説明した手法を使って、カーネルパニックの事後分析を効果的に行うことができます。パニックダンプの情報は、最初は暗号のように見えたかもしれませんが、これで、Mac OS X の開発者にとって有用なデバッグツールの 1 つになったはずです。

先頭に戻る

参考文献

¹The Design and Implementation of the 4.4BSD Operating System、McKusick 他共著 Addison-Wesley 刊 1996 年

PowerPC Microprocessor Family: The Programming Environments For 32-Bit Microprocessors, IBM Microelectronics ドキュメント G522-0290-01 2000 年 2 月 21 日改訂

Programming Environments Manual For 32-Bit Implementations of the PowerPC Architecture, Motorola ドキュメント MPCFPE32B/AD, REV 2, 2001 年 12 月改訂

先頭に戻る

ダウンロード

先頭に戻る